NAGWare f95 Compiler Release 5.1 Release Note

Introduction

Release 5.1 of the NAGWare f95 Compiler contains significant improvements to the compiler and substantial additions to the Fortran 2003 language features.

Compatibility with Earlier Releases

Except as noted below, NAGWare f95 5.1 is fully compatible with NAGWare f90 Releases 2.1 and 2.2, as well as with NAGWare f95 Releases 1.0, 4.0, 4.1, 4.2 and 5.0.

The following incompatibilities are introduced in this release:

New Features

This release contains the major new Fortran 2003 features of C interoperability and type-bound procedures. A number of minor Fortran 2003 features have been added, for example in the area of input/output.

This release also contains performance enhancements and many minor enhancements.

Major Fortran 2003 Features

C interoperability

The ISO_C_BINDING module

The intrinsic module ISO_C_BINDING contains These are described in more detail in the module's documentation.

BIND(C) types

Derived types corresponding to C struct types can be created by giving the type the BIND(C) attribute, e.g. 
  TYPE,BIND(C) :: mytype
The components of a BIND(C) type must have types corresponding to C types, and cannot be pointers or allocatables. Furthermore, a BIND(C) type cannot be a SEQUENCE type (it already acts like a SEQUENCE type), cannot have type-bound procedures, and cannot be extended.

BIND(C) variables

Access to C global variables is provided by giving the Fortran variable the BIND(C) attribute. Such a variable can only be declared in a module, and cannot be in a COMMON block. By default, the C name of the variable is the Fortran name converted to all lowercase characters; a different name may be specified with the NAME= clause, e.g. 
  INTEGER,BIND(C,NAME="StrangelyCapiTalisedCName") :: x
Within Fortran code, the variable is referred to by its Fortran name, not its C name.

BIND(C) procedures

A Fortran procedure that can be called from C can be defined using the BIND(C) attribute on the procedure heading. By default its C name is the Fortran name converted to lowercase; a different name may be specified with the NAME= clause. For example 
  SUBROUTINE sub() BIND(C,NAME='Sub')
  ...
Again, the C name is for use only from C, the Fortran name is used from Fortran. If the C name is all blanks (or a zero-length string), there is no C name. Such a procedure can still be called from C via a procedure pointer (i.e. by assigning it to a TYPE(C_FUNPTR) variable).

All BIND(C) procedures must have an explicit interface.

A BIND(C) procedure may be a subroutine or a scalar function with a type corresponding to a C type. Each dummy argument must be a variable whose type corresponds to a C type, and cannot be allocatable, assumed-shape, optional or a pointer. If the dummy argument does not have the VALUE attribute, it corresponds to a C dummy argument that is a pointer.

Here is an example of a Fortran procedure together with its reference from C: 

  SUBOUTINE find_minmax(x,n,max,min) BIND(C,NAME='FindMinMax')
    USE iso_c_binding
    REAL(c_double) x(*),max,min
    INTEGER(c_int),VALUE :: n
    INTRINSIC maxval,minval
    max = MAXVAL(x(:n))
    min = MINVAL(x(:n))
  END

  extern void FindMinMax(double *x,int n,double *maxval,double *minval);
  double x[100],xmax,xmin
  int n;
  ...
  FindMinMax(x,n,&xmax,&xmin);

This also allows C procedures to be called from Fortran, by describing the C procedure to be called in an interface block. Here is an example: 

  /* This is the prototype for a C library function from 4.3BSD. */
  int getloadavg(double loadavg[],int nelem);

PROGRAM show_loadavg
  USE iso_c_binding
  INTERFACE
    FUNCTION getloadavg(loadavg,nelem) BIND(C)
      IMPORT c_double,c_int
      REAL(c_double) loadavg(*)
      INTEGER(c_int),VALUE :: nelem
      INTEGER(c_int) getloadavg
    END FUNCTION
  END INTERFACE
  REAL(c_double) averages(3)
  IF (getloadavg(averages,3)/=3) THEN
    PRINT *,'Unexpected error'
  ELSE
    PRINT *,'Load averages:',averages
  END IF
END

Enumerations

An enumeration defines a set of integer constants of the same kind, and is equivalent to the C enum declaration. For example, 
  ENUM,BIND(C)
    ENUMERATOR :: open_door=4, close_door=17
    ENUMERATOR :: lock_door
  END ENUM
is equivalent to 
  enum {
    open_door=4, close_door=17,
    lock_door
  };
If a value is not given for one of the enumerators, it will be one greater than the previous value (or zero if it is the first enumerator in the list). The kind used for a particular set of enumerators can be discovered by using the KIND intrinsic on one of the enumerators.

Note that the BIND(C) clause is required; the standard only defines enumerations in the context of interoperating with C.

Type-bound procedures

Type-bound procedures provide a means of packaging operations on a type with the type itself, and also for dynamic dispatch to a procedure depending on the dynamic type of a polymorphic variable.

The type-bound procedure part

The type-bound procedure part of a type definition is separated from the components by the CONTAINS statement. The default accessibility of type-bound procedures is public even if the components are private; this may be changed by using the PRIVATE statement after the CONTAINS.

Specific type-bound procedures

The syntax of a specific, non-deferred, type-bound procedure declaration is:
PROCEDURE [[,binding-attr-list]::] binding-name [=>procedure-name]

The name of the type-bound procedure is binding-name, and the name of the actual procedure which implements it is procedure-name. If the optional =>procedure-name is omitted, the actual procedure has the same name as the binding.

A type-bound procedure is invoked via an object of the type, e.g. 

  CALL variable(i)%tbp(arguments)
Normally, the invoking variable is passed as an extra argument, the ``passed-object dummy argument''; by default this is the first dummy argument of the actual procedure and so the first argument in the argument list becomes the second argument, etc. The passed-object dummy argument may be changed by declaring the type-bound procedure with the PASS(argument-name) attribute, in which case the variable is passed as the named argument. The PASS attribute may also be used to confirm the default (as the first argument), and the NOPASS attribute prevents passing the object as an argument at all. The passed-object dummy argument must be a polymorphic scalar variable of that type, e.g. CLASS(t) self.

When a type is extended, the new type either inherits or overrides each type-bound procedure of the old type. An overriding procedure must be compatible with the old procedure; in particular, each dummy argument must have the same type except for the passed-object dummy argument which must have the new type. A type-bound procedure that is declared to be NON_OVERRIDABLE cannot be overridden during type extension.

When a type-bound procedure is invoked, it is the dynamic type of the variable which determines which actual procedure to call.

The other attributes that a type-bound procedure may have are PUBLIC, PRIVATE, and DEFERRED (the latter only for abstract types, which are described later).

Generic type-bound procedures

A generic type-bound procedure is a set of specific type-bound procedures, in the same way that an ordinary generic procedure is a set of specific ordinary procedures. It is declared with the GENERIC statement, e.g. 
  GENERIC :: generic_name => specific_name_1, specific_name_2, specific_name_3
Generic type-bound procedures may also be operators or assignment, e.g. 
  GENERIC :: OPERATOR(+) => add_t_t, add_t_r, add_r_t
Such type-bound generic operators cannot have the NOPASS attribute; the dynamic type of the passed-object dummy argument determines which actual procedure is called.

When a type is extended, the new type inherits all the generic type-bound procedures without exception, and the new type may extend the generic with additional specific procedures. To override procedures in the generic, simply override the specific type-bound procedure. For example, in 

  TYPE mycomplex
    ...
  CONTAINS
    PROCEDURE :: myc_plus_r => myc1_plus_r
    PROCEDURE,PASS(B) :: r_plus_myc => r_plus_myc1
    GENERIC :: OPERATOR(+) => myc_plus_r, r_plus_myc
  END TYPE
  ...
  TYPE,EXTENDS(mycomplex) :: mycomplex_2
    ...
  CONTAINS
    PROCEDURE :: myc_plus_r => myc2_plus_r
    PROCEDURE,PASS(B) :: r_plus_myc => r_plus_myc2
  END TYPE
the type mycomplex_2 inherits the generic operator ``+''; invoking the generic (+) invokes the specific type-bound procedure, which for entities of type mycomplex_2 will invoke the overriding actual procedure (myc2_plus_r or r_plus_myc2).

Other Fortran 2003 Features

Input/output Features

Stream input/output

Stream access files have been added, including the NEW_LINE intrinsic function. These files are opened with ACCESS='STREAM', and may be formatted or unformatted.

A formatted stream file is equivalent to a C text stream; this acts much like an ordinary sequential file, except that there is no limit on the length of a record. Just as in C, when writing to a formatted stream, an embedded newline character in the data causes a new record to be created. The NEW_LINE function returns this character. For example, 

  OPEN(17,FORM='formatted',ACCESS='stream',STATUS='scratch')
  WRITE(17,'(A)') 'This is record 1.'//NEW_LINE('A')//'This is record 2.'

An unformatted stream file is equivalent to a C binary stream, and has no record boundaries. This makes it impossible to BACKSPACE an unformatted stream. Data written to an unformatted stream is transferred to the file with no formatting, and data read from an unformatted stream is transferred directly to the variable as it appears in the file.

When reading or writing a stream file, the POS= specifier may be used to specify where in the file the data is to be written. The first character of the file is at position 1. The POS= specifier may also be used in an INQUIRE statement, in which case it returns the current position in the file. When reading or writing a formatted stream, the POS= in a READ or WRITE shall be equal to 1 (i.e. the beginning of the file) or to a value previously discovered through INQUIRE.

Note that unlike unformatted sequential files, writing to an unformatted stream file at a position earlier than the end of the file does not truncate the file. (However, this truncation does happen for formatted streams.)

The BLANK= and PAD= specifiers

The BLANK= and PAD= specifiers, which previously were only allowed on an OPEN statement (and INQUIRE), are now allowed on a READ statement. These change the BLANK= or PAD= mode for the duration of that READ statement only.

Decimal Comma

Support for decimal comma input/output has been added; this consists of the DECIMAL= specifier and the DC and DP edit descriptors. The DECIMAL= specifier may appear in OPEN, READ, WRITE and INQUIRE statements; possible values are 'POINT' (the default) and 'COMMA'. For an unconnected or unformatted unit, INQUIRE returns 'UNDEFINED'. The DC edit descriptor temporarily sets the mode to DECIMAL='COMMA', and the DP edit descriptor temporarily sets the mode to DECIMAL='POINT'.

When the mode is DECIMAL='COMMA', all floating-point output will produce a decimal comma instead of a decimal point, and all floating-point input will expect a decimal comma. Additionally, in this mode, a comma cannot be used in list-directed input to separate items; instead, a semi-colon may be used.

The DELIM= specifier

The DELIM= specifier, which previously was only allowed on an OPEN statement (and INQUIRE), is now allowed on a WRITE statement. It changes the DELIM= mode for the duration of that WRITE statement; note that this only has any effect if the WRITE statement uses list-directed or namelist output.

The ENCODING= specifier

The ENCODING= specifier has been added to the OPEN and INQUIRE statements. At this time the only encoding supported is 'ASCII'.

The IOMSG= specifier

The IOMSG= specifier has been added to all input/output statements. This takes a scalar default character variable, which in the event of an error is assigned an explanatory message. (Note that this is only useful if the statement contains an IOSTAT= or ERR= specifier, otherwise the program will be terminated on error anyway.) If no error occurs, the value of the variable remains unchanged.

The IOSTAT= specifier

This now accepts any kind of integer variable (previously this was required to be default integer).

The SIGN= specifier

The SIGN= specifier has been added to the OPEN, WRITE and INQUIRE statements; possible values are 'PLUS', 'SUPPRESS' and 'PROCESSOR_DEFINED' (the default). For NAGWare f95, SIGN='PROCESSOR_DEFINED' has the same effect as SIGN='SUPPRESS'.

The effect of SIGN='PLUS' is the same as the SP edit descriptor, the effect of SIGN='SUPPRESS' is the same as the SS edit descriptor, and the effect of SIGN='PROCESSOR_DEFINED' is the same as the S edit descriptor.

New intrinsic functions

The intrinsic functions IS_IOSTAT_END and IS_IOSTAT_EOR have been added, for testing IOSTAT= return values. These are equivalent to testing the IOSTAT= return value against the named constants IOSTAT_END and IOSTAT_EOR respectively; these constants are available through the ISO_FORTRAN_ENV module.

Input/output of IEEE infinities and NaNs

Output of IEEE infinities and NaNs has been changed to: Furthermore, the output is right-justified within the output field. For list-directed output the output field is the minimum size to hold the result.

Input of IEEE infinities and NaNs is now possible; these take the same form as the output described above, except that:

The result of reading a NaN value is always a quiet NaN, never a signalling one.

Output of floating-point zero

List-directed and namelist output of floating-point zero is now done using F format instead of E format.

NAMELIST and internal files

Namelist input/output is now permitted to/from internal files.

Asynchronous input/output syntax

Asynchronous input/output syntax is accepted; this consists of the ASYNCHRONOUS= specifier on OPEN, READ, WRITE and INQUIRE, and the ID= and PENDING= specifiers on READ, WRITE and INQUIRE. At this time all actual i/o operations remain synchronous. The WAIT statement and the ASYNCHRONOUS attribute are not yet available.

Miscellaneous Features

Abstract derived types

An extensible derived type can be declared to be ABSTRACT, e.g. 
  TYPE, ABSTRACT :: mytype
An abstract type cannot be instantiated; i.e. it is not allowed to declare a non-polymorphic variable of abstract type, and a polymorphic variable of abstract type must be allocated to be a non-abstract extension of the type.

Abstract type may contain DEFERRED type-bound procedures, e.g. 

  ...
  CONTAINS
    PROCEDURE(interface_name),DEFERRED :: tbpname
No binding (``=> name'') is allowed or implied by a deferred procedure binding. The interface_name must be the name of an abstract interface or a procedure with an explicit interface, and defines the interface of the deferred type-bound procedure.

When extending an abstract type, the extended type must also be abstract unless it overrides all of the deferred type-bound procedures with normal bindings.

Abstract interfaces and the PROCEDURE statement

Abstract interfaces have been added, together with the procedure declaration statement. An abstract interface is defined in an interface block that has the ABSTRACT keyword, i.e. 
  ABSTRACT INTERFACE
Each interface body in an abstract interface block defines an abstract interface instead of declaring a procedure. The name of an abstract interface can be used in the procedure declaration statement to declare a specifc procedure with that interface, e.g. 
  PROCEDURE(aname) :: spec1, spec2
declares SPEC1 and SPEC2 to be procedures with the interface (i.e. type, arguments, etc.) defined by the abstract interface ANAME.

The procedure declaration statement can also be used with the name of any procedure that has an explicit interface, e.g. 

  PROCEDURE(x) y
declares Y to have the same interface as X. Finally, procedures with implicit interfaces can be declared by using PROCEDURE with a type specification instead of a name, or by omitting the name altogether.

Individual component accessibility

It is now possible to set the accessibility of individual components in a derived type. For example, 
  TYPE t
    LOGICAL, PUBLIC :: flag
    INTEGER, PRIVATE :: state
  END TYPE
The structure constructor for the type is only available outside the defining module if all components are public.

Public entities of private type

It is now possible to export entities (named constants, variables, procedures) from a module even if they have private type or (for procedures) have arguments of private type. For example, 
  MODULE m
    TYPE, PRIVATE :: hidden_type
      CHARACTER(6) :: code
    END TYPE
    TYPE(hidden_type), PUBLIC, PARAMETER :: code_green = hidden_type('green')
    TYPE(hidden_type), PUBLIC, PARAMETER :: code_yellow = hidden_type('yellow')
    TYPE(hidden_type), PUBLIC, PARAMETER :: code_red = hidden_type('red')
  END

The ISO_FORTRAN_ENV module

The standard intrinsic module ISO_FORTRAN_ENV is now available. This contains implementation-dependent named constants, and is described fully in its own documentation.

The IMPORT statement

The IMPORT statement has been added. This has the form
IMPORT [ [ :: ] name [ , name ]... ]
and is only allowed in an interface body, where it imports the named entities from the host scoping unit (normally, these entities cannot be accessed from an interface body). If no names are specified, normal host association rules are in effect for this interface body.

The IMPORT statement must follow any USE statements and precede all other declarations, in particular, IMPLICIT and PARAMETER statements. Anything imported with IMPORT must have been declared prior to the interface body.

INTENT for pointers

A POINTER dummy argument may now have the INTENT attribute. This attribute applies to the pointer association status, not to the target of the pointer.

An INTENT(IN) pointer can be assigned to, but cannot be pointer-assigned, nullified, allocated or deallocated. An INTENT(OUT) pointer receives an undefined association status on entry to the procedure. An INTENT(INOUT) pointer has no restrictions on its use, but the actual argument must be a pointer variable, not a pointer function reference.

Square brackets for array constructors

Square brackets ([ ]) can now be used in place of the parenthesis-slash pairs ((/ /)) for array constructors.

The SOURCE= specifier

The ALLOCATE statement now accepts the SOURCE= specifier. The dynamic type and value of the allocated entity is taken from the expression in the specifier. Note that when allocating an array the array shape is not taken from the SOURCE= specifier but must be specified in the usual way.

The ERRMSG= specifier

The ALLOCATE and DEALLOCATE statements now accept the ERRMSG= specifier. This specifier takes a scalar default character variable, which in the event of an allocation or deallocation error being detected will be assigned an explanatory message. If no error occurs the variable is left unchanged. Note that this is useless unless the STAT= specifier is also used, as otherwise the program will be terminated on error anyway.

Access to the command line

The intrinsic procedures COMMAND_ARGUMENT_COUNT, GET_COMMAND and GET_COMMAND_ARGUMENT have been added. These duplicate functionality previously only available via the procedures IARGC and GETARG from the F90_UNIX_ENV module. 

INTEGER FUNCTION command_argument_count()
END
Returns the number of command-line arguments. Unlike IARGC in the F90_UNIX_ENV module, this returns 0 even if the command name cannot be retrieved. 

SUBROUTINE get_command(command,length,status)
  CHARACTER(*),INTENT(OUT),OPTIONAL :: command
  INTEGER,INTENT(OUT),OPTIONAL :: length,status
END
Accesses the command line which invoked the program. This is formed by concatenating the command name and the arguments separated by blanks. This might differ from the command the user actually typed, and should be avoided (use GET_COMMAND_ARGUMENT instead).

If COMMAND is present, it receives the command (blank-padded or truncated as appropriate). If LENGTH is present, it receives the length of the command. If STATUS is present, it is set to -1 if COMMAND is too short to hold the whole command, a positive number if the command cannot be retrieved, and zero otherwise. 

SUBROUTINE get_command_argument(number,value,length,status)
  INTEGER,INTENT(IN) :: number
  CHARACTER(*),INTENT(OUT),OPTIONAL :: value
  INTEGER,INTENT(OUT),OPTIONAL :: length,status
END
Accesses command-line argument number NUMBER, where argument zero is the program name. If VALUE is present, it receives the argument text (blank-padded or truncated as appropriate if the length of the argument differs from that of VALUE). If LENGTH is present, it receives the length of the argument. If STATUS is present, it is set to zero for success, -1 if VALUE is too short, and a positive number if an error occurs.

Note that it is an error for NUMBER to be less than zero or greater than the number of arguments (returned by COMMAND_ARGUMENT_COUNT).

Access to environment variables

The intrinsic procedure GET_ENVIRONMENT_VARIABLE has been added. This duplicates the functionality previously only available via the procedure GETENV in the F90_UNIX_ENV module. 
  SUBROUTINE get_environment_variable(name,value,length,status,trim_name)
    CHARACTER(*),INTENT(IN) :: name
    CHARACTER(*),INTENT(OUT),OPTIONAL :: value
    INTEGER,INTENT(OUT),OPTIONAL :: length,status
    LOGICAL,INTENT(IN),OPTIONAL :: trim_name
  END
Accesses the environment variable named by NAME; trailing blanks in NAME are ignored unless TRIM_NAME is present with the value false. If VALUE is present, it receives the text value of the variable (blank-padded or truncated as appropriate if the length of the value differs from that of VALUE). If LENGTH is present, it receives the length of the value. If STATUS is present, it is assigned the value 1 if the environment variable does not exist, -1 if VALUE is too short, and zero for success. Other positive values might be assigned for unusual error conditions.

Character kind selection

The intrinsic function SELECTED_CHAR_KIND has been added. At this time the only character set supported is 'ASCII'.

Argument passing relaxation

A CHARACTER scalar actual argument may now be passed to a routine which expects to receive a CHARACTER array, provided the array is explicit-shape or assumed-size (i.e. not assumed-shape, allocatable, or pointer). This is useful for C interoperability.

The MAXLOC and MINLOC intrinsic functions

The MAXLOC and MINLOC intrinsic functions now return zeroes for empty set locations, as required by Fortran 2003 (Fortran 95 left this result processor-dependent).

Performance Enhancements

Other Enhancements

New Fortran Standard

The extensions (described above) which follow the rules of the Fortran 2003 standard are listed below together with the appropriate section number for the reference book ``Fortran 95/2003 Explained'' by Metcalf, Reid & Cohen, Oxford University Press, 2005 printing (ISBN 0-19-852693-89).